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Abstract 


While  the  lure  of  easy  system  construction  from  pre-existing  building  blocks  that  snap  into 
place  is  appealing,  current  reality  reveals  a  less  than  ideal  picture,  particularly  for  commercial 
off-the-shelf  (COTS)  software  components.  Examining  the  similarities  and  differences  of 
organizations  that  have  applied  COTS  and  the  successes  and  failures  of  those  organizations 
has  enabled  the  COTS-Based  Systems  (CBS)  Initiative  at  the  Software  Engineering  Institute 
(SEI)  to  identify  a  number  of  significant  capabilities  that  an  organization  must  have  to 
succeed  with  a  COTS-based  approach.  This  case  study  of  the  Manufacturing  Resource 
Planning  II  program  is  part  of  a  series  of  case  studies  that  seek  to  identify  important 
acquisition,  business,  and  engineering  issues  surrounding  the  use  of  COTS-based  systems 
and  thus  derive  available  solutions,  where  possible. 
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1  Introduction 


The  use  of  existing  “off-the-sheif  ’  (OTS)  products  to  produce  systems  is  accelerating. 

Interest  in  applying  a  full  or  partial  OTS  solution  is  fueled  by  the  need  of  organizations  to 
acquire  functioning  systems  faster  and,  potentially,  at  a  reduced  cost.  This  can  be  an  effective 
long-term  approach  to  system  development,  maintenance,  and  reengineering. 

While  the  lure  of  easy  system  construction  from  pre-existing  building  blocks  that  snap  into 
place  is  appealing,  current  reality  reveals  a  less  than  ideal  picture,  particularly  for  commercial 
OTS  (COTS)  software  products.  Available  COTS  software  seldom  fits  harmoniously  with 
other  system  components  without  some  amount  of  adaptation  to  make  all  the  components 
work  together.  Currently,  there  is  limited  experience  and  available  guidance  on  how  to 
effectively  approach  the  acquisition  and  maintenance  of  software-intensive  systems  built 
using  COTS  software. 


The  COTS-Based  Systems  (CBS)  Initiative  is  one  of  the  technical  engineering  practice 
initiatives  at  the  Software  Engineering  Institute  (SEI)  and  is  aimed  at  establishing  and 
demonstrating  principles  and  practices  for  integrating  and  evolving  systems  from  previously- 
built  and  COTS  products.  This  includes  methods  for  evaluating  the  suitability  and  quality  of 
products,  methods  for  integrating  products  into  operational  systems,  and  acquisition  and 
business  practices  that  permit  the  effective  use  of  CBS  engineering  practices. 

Examining  the  similarities  and  differences  of  organizations  that  have  applied  COTS  and  the 
successes  and  failures  of  those  organizations  has  enabled  us  to  identify  a  number  of 
significant  capabilities  that  an  organization  must  have  to  succeed  with  a  COTS-based 
approach.  This  case  study  lists  lessons  learned  from  one,  successful,  Department  of  Defense 
(DoD)  acquisition  of  a  COTS-based  system. 

This  report  briefly  describes  the  program  and  the  interview  process.  Then,  the  lessons  learned 
by  the  program  are  discussed;  these  lessons  have  been  grouped  into  seven  categories.  Finally, 
some  general  conclusions  are  drawn  concerning  this  acquisition. 
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1.1  COTS  Terminology 

The  terms  OTS  and  COTS  are  often  used  to  refer  to  products  and  services  other  than  software. 
Although  the  focus  of  the  CBS  Initiative  is  on  the  use  of  software  products  in  software¬ 
intensive  systems,  we  are  finding  that  many  of  the  issues  uncovered  through  the  case  studies 
are  applicable  to  hardware. 

In  our  usage  COTS-based  systems  are  composed  of  software  components  that 

•  are  ready  and  "off-the-shelf,"  with  a  predominance  from  a  commercial  source  (COTS). 
Government  off-the-shelf  (GOTS),  non-developmental  items  (NDI),  or  components 
reused  from  a  legacy  system  may  be  included. 

•  have  significant  functionality  and  complexity 

•  are  self-contained  and  possibly  execute  independently 

•  are  generally  used  "as  is"  rather  than  requiring  internal  modification 

•  may  be  integrated  with  other  components  to  achieve  required  system  functionality 

There  are  different  types  of  COTS-based  systems,  leading  to  different  implications  for 
business,  engineering,  and  management  practices. 

At  one  end  of  the  CBS  spectrum  are  COTS-solution  systems.  These  systems  comprise  a 
single  product  or  product  suite,  provided  one  vendor,  that  may  be  tailored  to  provide  the 
system’s  functionality.  The  amount  of  tailoring,  data  conversion,  and  business  practice 
reengineering  is  often  significant.  These  systems  may  be  found  in  application  areas  with 
general  concurrence  on  application  practices,  examples  being  personnel  management  and 
financial  management  applications.  PeopleSoft  and  Oracle  are  typical  vendors. 

At  the  other  end  of  the  CBS  spectrum  are  COTS-aggregate  systems.  These  systems  are 
composed  of  many  products,  usually  from  different  vendors,  and  other  OTS  components  that 
are  integrated  to  provide  the  system’s  functionality.  Often  the  use  of  the  particular  set  of 
components  is  unprecedented  and  requires  substantial  resources  to  select  and  integrate  a 
cohesive  set  of  components.  These  systems  may  be  found  where  the  needs  of  the  system 
cannot  be  satisfied  by  a  single  product  or  product  suite  or  when  the  system’s  operational 
procedures  are  unique. 
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1.2  Program’s  Background 

The  Manufacturing  Resource  Planning  (MRP)  II  program  has  the  same  name  as  the  business 
practice  approach.  To  avoid  confusion  throughout  this  report,  we  will  distinguish  between  the 
MRP  II  program  itself  and  the  MRP  II  philosophy. 

The  MRP  II  program  is  responsible  for  the  acquisition  and  installation  of  a  system  to  perform 
the  business  functions  for  maintenance  depots  of  the  DoD  in  all  services.  The  system  chosen 
embodies  the  MRP  II  philosophy,  which  is  an  extension  of,  and  controls  more  of  the 
manufacturing  business  than,  the  earlier  Material  Requirements  Planning  process.  The  MRP 
II  philosophy  is  an  established  domain  of  manufacturing  practices  with  established  standards 
and  professional  groups.  The  MRP  II  program  selected  the  Com/wmCONTRACT®  product 
suite  from  Western  Data  Systems  Inc.  (WDS)1. 

The  typical  business  of  the  maintenance  depots  is  to  take  a  DoD  asset,  such  as  a  helicopter  or 
tank,  strip  it  down  to  its  carcass,  and  then  rebuild  the  asset.  The  parts  used  to  rebuild  the  asset 
may  be  those  that  came  with  it  if  they  are  undamaged.  They  could  also  be  newly 
manufactured  or  repaired  parts.  The  overall  result  is  that  the  asset  undergoes  routine  but 
large-scale  maintenance,  where  every  part  of  the  asset  is  checked  thoroughly  for  flaws  and 
repaired  if  necessary. 

Depot  maintenance  benefits  from  the  MRP  II  philosophy,  as  it  is  statistically  predictable. 
Statistically,  maintenance  of  one  asset  requires  the  same  level  of  effort  and  replacement  parts 
as  the  next.  If  the  parts  and  labor  are  known  to  be  available  before  the  arrival  of  the  asset,  the 
entire  maintenance  effort  may  be  performed  as  efficiently  as  possible.  The  examination  of 
records  determines  a  statistical  baseline  that  may  be  adjusted  as  data  is  collected  in 
subsequent  maintenance. 

The  MRP  II  program  is  part  of  an  overall  strategy  to  maximize  the  commonality  of  business 
processes  across  all  depots  for  all  of  the  services.  The  MRP  II  program  automates  a 
significant  piece  of  the  depot’s  business  systems.  In  part,  the  MRP  II  program  is  the  result  of 
the  U.S.  Air  Force’s  Depot  Maintenance  Management  Information  System  (DMMIS),  that 
attempted  to  bring  together  the  best  components  from  each  depot’s  suite  of  business  systems 
to  create  a  single  depot  management  system.  The  DMMIS  program,  which  was  based  on 
different  custom  software  and  modified  COTS  products,  was  unsuccessful,  and  the  Joint 
Logistics  Systems  Center  was  tasked  to  provide  a  new  system,  resulting  in  the  MRP  II 
program. 


1  It  should  be  noted  that  WDS  integrates  COTS  products  into  Cw/i/w.v.vCONTRACT.  The  underlying 
database  is  from  Oracle  Corporation,  and  one  component  of  the  suite  comes  from  another  vendor. 
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1.3  Program’s  COTS  Approach 

The  MRP  II  program  began  in  early  1995.  Prior  to  starting  any  source-selection  activities,  the 
program  conducted  a  three-month  COTS  feasibility  study  followed  by  a  three-month 
requirement  definition  effort.  Source  selection  began  with  the  Commerce  Business  Daily 
(CBD)  announcement  in  the  fall  of  1995.  A  fixed-price  contract  was  awarded  to  WDS  in  the 
fall  of  1996  with  the  contract  starting  in  early  1997.  The  initial  pilot  site  installation  began  in 
mid  1997.  The  WDS  product,  like  many  COTS-solution  systems,  required  substantial 
attention  to  business  process  reengineering  and  data  conversion  for  effective  deployment.  As 
such,  the  program’s  emphasis  at  this  point  focused  on  determining  effective  transition 
guidance  for  fielding  into  DoD  depots.  Additional  site  installation  to  early  adopters  began  in 
the  fall  of  1997. 

The  MRP  II  program  continues  to  deploy  the  system.  Depots  are  in  various  stages  of 
transition  ranging  from  full  implementation  (when  cut-over  from  legacy  systems  is  complete) 
to  early  training  and  migration  planning.  Depot  success  with  the  MRP  II  philosophy  and 
WDS  product  has  also  varied.  Successful  depots  have  generally  seen  the  MRP  II  philosophy 
as  central  to  their  own  success,  understood  that  some  amount  of  business  process 
reengineering  is  required  to  leverage  the  business  approach  (and  the  WDS  product),  and 
exhibited  strong  leadership  throughout  all  transition  phases. 

We  would  characterize  the  MRP  II  program  as  a  COTS-solution  system  since  the  WDS 
product  suite  forms  the  system  for  the  MRP  II  program.  The  essential  elements  of  the 
program’s  COTS  approach  can  be  summarized  as  follows: 

•  The  government  would  adopt  commercial  practices  that  were  not  in  direct  conflict  with 
DoD  regulations. 

•  The  government  would  lead  a  cross-service  requirement  effort  augmented  with  industry 
experts  in  the  area  of  the  MRP  II  philosophy. 

•  The  new  system,  provided  by  the  MRP  II  program,  would  not  attempt  to  perform  all 
depot  management  functions.  Rather,  it  would  perform  a  partial,  but  significant,  set  of 
common,  core  functions. 

•  No  modification  of  the  COTS  product  suite’s  software  to  create  government-specific 
features  would  be  allowed. 

•  The  government  would  take  responsibility  for  the  selection  of  the  COTS  product  suite. 

•  The  MRP  II  program  office  would  take  responsibility  for  installing  the  software  at  the 
various  depots  and  providing  seed  money  to  assist  the  depots  in  the  deployment  of  the 
MRP  II  philosophy  at  their  sites. 

•  Each  depot  would  be  responsible  for  determining  gaps  between  its  business  processes 
and  those  supported  by  the  selected  product,  performing  any  necessary  business  process 
reengineering,  developing  and  managing  the  necessary  site  transition,  and  providing  any 
necessary  integration  with  other  systems  at  its  site.  Additionally,  each  depot  was 
responsible  for  providing  any  contractor  support  for  these  activities. 
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•  The  MRP  II  program  office  would  establish  and  maintain  an  active  presence  within  the 
manufacturing  resource  planning  community  by  participating  in  the  vendor’s  user  group, 
professional  groups,  and  standards  organizations. 

•  The  MRP  II  program  office  would  establish  and  maintain  a  long-term  partnership  with 
the  selected  COTS  vendor. 

1 .4  Review  Process 

The  MRP  II  review  was  conducted  by  holding  an  initial  meeting,  preparing  for  the  review, 
performing  the  review,  and  analyzing  the  data. 

The  initial  meeting  was  held  via  teleconference  in  January  1998.  Participants  were  the  MRP 
II  program  manager,  the  MRP  II  program  office  support  contractor,  and  the  SEI.  The  purpose 
of  the  meeting  was  to  lay  the  foundation  for  the  review  and  help  the  SEI  understand  the  status 
and  scope  of  the  MRP  II  program.  As  a  result  of  the  meeting,  the  review  was  structured  into 
two  parts.  The  first  part  of  the  review  would  consist  of  a  visit  with  the  program  office;  the 
second  part  would  involve  visiting  one  or  more  depots.  Actual  sites  would  be  selected  during 
the  program  office  visit. 

SEI  pre-review  preparation  involved  the  development  of  a  questionnaire  as  well  as  gaining  a 
better  understanding  of  politically  sensitive  issues  and  the  purpose  and  products  of  the 
review. 

The  program  office  review  was  conducted  over  two  days  in  February  1998  at  the  MRP  II 
program  office.  The  SEI  team  consisted  of  two  senior  staff  members  from  the  CBS  Initiative. 
Due  to  the  small  size  of  the  program  office,  interviews  were  conducted  in  a  group  setting. 

The  interview  participants  included  the  MRP  II  program  manager,  the  deputy  MRP  II 
program  manager,  and  several  contractor  staff  members  who  had  provided  program  office 
support  from  source  selection  to  the  present. 

At  the  completion  of  the  interviews,  the  status  of  each  deployed  site  was  discussed.  The  sites 
selected  for  inclusion  in  the  SEI  review  were  the  Air  Force  Aerospace  Maintenance  and 
Regeneration  Center  (AMARC)  in  Tucson,  AZ  and  the  Naval  Aviation  Depot  (NADEP)  at 
Cherry  Point,  NC.  Both  sites  were  sufficiently  far  along  in  the  deployment  of  MRP  II  to 
provide  useful  data.  The  SEI  team  for  the  deployed  site  reviews  would  remain  the  same.  The 
deputy  program  manager  from  the  MRP  II  program  office  would  accompany  the  SEI  team  to 
provide  any  necessary  context. 

The  review  of  AMARC  was  conducted  during  a  one-day  site  visit  in  February  1998.  The 
interview  participants  included  the  program  director  responsible  for  the  transition  to  MRP  II, 
the  contractor  project  lead  providing  transition  support  to  AMARC,  and  the  technical 
consultant  providing  specific  assistance  in  mapping  the  MRP  II  philosophy  and  the  WDS 
product  to  the  specific  business  environment  at  AMARC. 
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The  review  of  the  NADEP,  Cherry  Point  was  conducted  in  a  one-day  site  visit  in  March  1998. 
The  interview  participants  included  the  commanding  officer,  the  executive  officer,  and  the 
MRP  II  site  lead. 

The  next  steps  were  to  analyze  the  collected  data  from  all  the  site  visits,  develop  a  detailed 
set  of  findings,  and  document  the  lessons  learned.  Section  2  records  the  lessons  learned  and 
their  associated  findings. 

1.5  Acknowledgements 
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2  Lessons  Learned 


The  MRP  II  lessons  learned  are  organized  into  the  following  categories: 

•  business  processes 

•  product  evaluation  and  acquisition 

•  programmatic  issues 

•  transition  issues 

•  user  communities 

•  deployment 

•  vendor  relationship  management 

No  attempt  was  made  to  collect  the  data  in  the  above  categories  or  order.  The  organization 
arose  during  the  detailed  analysis  of  the  raw  data  and  also  due  to  similarities  with  other 
reviews.  Some  lessons  were  derived  from  a  single  interview  and  other  lessons  were  derived 
from  multiple  interviews.  However,  no  attempt  has  been  made  to  sort  the  lessons  according  to 
this  criterion. 
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2.1  Lessons  on  Business  Processes 

The  lessons  learned  about  business  processes  are  discussed  below. 

2.1.1  Operating  in  a  commercial  manner  allows  a  greater  use  of 
COTS  products. 

If  a  DoD  organization  is  to  purchase  a  COTS-based  system,  it  must  be  prepared  to  operate  in 
a  more  commercial  manner.  All  software  packages  include  assumptions  about  the  way  in 
which  they  will  be  used;  violating  these  assumptions  means  that  the  software  will  be  hard  to 
use.  In  the  case  of  the  MRP  II  program,  the  maintenance  depots  have  shown  that  it  is  possible 
to  adapt  their  business  processes  to  those  of  the  commercial  world.  Because  the  depots  were 
willing  to  change  their  business  processes,  the  program  office  was  able  to  purchase  COTS 
software  supporting  the  remanufacturing  business  rather  than  having  to  develop  and  maintain 
a  customized  system. 

2.1.2  Business  processes  should  be  reengineered  before  and  during 
automation. 

The  MRP  II  program  office  performed  an  initial  examination  of  the  depots’  business  practices 
and  provided  a  general  notion  of  how  they  would  be  changed.  Each  depot  subsequently 
performed  a  more  rigorous  examination  of  its  specific  practices,  determining  how  it  could 
benefit  from  the  WDS  product. 

Software,  whether  COTS  or  customized,  does  not  change  or  improve  the  efficiency  of  an 
organization’s  business  processes;  it  merely  automates  those  processes.  A  COTS  business 
product  embodies  a  set  of  business  practices  that  may  be  different  than  those  used  by  the 
receiving  organization.  Thus,  deploying  a  COTS  product  to  automate  the  business  is  likely  to 
require  some  changes  to  the  organization’s  business  practices. 

The  introduction  of  software  should  be  delayed  until  the  process  of  reengineering  the 
business  processes  has  been  initiated.  However,  this  reengineering  cannot  take  place  in  a 
vacuum;  it  must  take  into  account  the  availability  of  products  to  support  the  new  practices. 

2.1.3  A  COTS  product  can  act  as  a  catalyst  for  improving  business 
processes. 

The  MRP  II  program  shows  that  the  introduction  of  software  can  act  as  a  catalyst,  helping  an 
organization  examine  business  processes  for  any  deficiencies  and  improving  those  processes. 
The  maintenance  depots  would  have  gained  benefits  simply  by  improving  their  processes. 
However,  optimizing  their  business  processes  to  take  advantage  of  the  WDS  product 
provided  greater  gain. 
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The  examination  of  business  processes  embodied  by  COTS  software  enables  DoD 
organizations  to  gain  some  insight  into  the  business  processes  of  the  commercial  world  and 
adopt  those  processes  that  make  sense  in  their  environment. 

2.1.4  It  is  easy  to  underestimate  the  time  it  takes  to  realistically 
understand  and  convert  to  new  business  processes. 

The  introduction  of  the  WDS  product  forced  each  depot  to  examine  its  business  practices  in 
order  to  use  the  software.  The  MRP  II  program  underestimated  the  amount  of  effort  it  takes  to 
understand  the  existing  business  processes  within  a  depot,  believing  that  the  depots  could 
adapt  to  the  MRP  II  philosophy  faster  than  industry.  Evidence  from  industry  indicates  that  the 
average  length  of  time  to  transition  to  the  MRP  II  philosophy  is  18  months,  yet  the  DoD 
estimated  it  could  make  the  transition  in  12.  There  is  no  real  reason  to  believe  that  the  DoD 
can  adapt  to  new  processes  faster  than  industry,  and  the  evidence  in  this  case  suggests  that  the 
conversion  time  was  similar  to  the  industry  norms. 

2.1.5  The  decision  to  use  a  COTS  product  may  require  a  change  in 
policy  or  in  business  processes  outside  of  a  program. 

The  choice  to  acquire  a  COTS-based  system  that  embodies  a  particular  set  of  business 
practices  may  have  ramifications  outside  a  DoD  program.  In  particular,  for  the  MRP  II 
program,  when  a  depot  chooses  to  use  the  WDS  product  to  report  financial  information  to  its 
commands,  those  commands,  and  possibly  the  DoD  as  a  whole,  must  approve  the  new 
reports. 
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2.2  Lessons  on  Product  Evaluation  and  Acquisition 

The  lessons  learned  about  product  evaluation  and  acquisition  are  discussed  below. 

2.2.1  Understanding  the  marketplace  in  relation  to  your  own 
business  is  vital. 

One  of  the  most  important  aspects  of  the  MRP  II  program  was  the  study  of  the  marketplace  to 
see  what  products  were  available  that  supported  the  MRP  II  philosophy.  This  study  enabled 
the  MRP  II  program  team  to  shape  its  requirements  so  that  COTS  software  could  be  acquired. 
If  the  DoD  (or  any  organization)  creates  requirements  without  examining  and  taking  into 
account  the  products  in  the  marketplace,  it  is  unlikely  that  those  requirements  can  be  met  by 
commercial  software. 

2.2.2  Create  a  representative  team  of  stakeholders  to  shape  the 
requirements. 

Many  individuals  with  different  functions  use  the  business  system  employed  by  the  depot.  It 
is  important  to  use  a  representative  sample  of  the  workforce  to  develop  the  requirements  so 
that  no  important  aspect  of  the  overall  function  of  the  depot  will  be  omitted.  In  addition,  for 
the  DoD,  it  is  important  that  these  representatives  come  from  each  of  the  services,  as  each 
service  is  likely  to  have  different  ways  of  performing  similar  functions.  The  representatives 
must  be  truly  representative  and,  ideally,  be  able  to  speak  for  others  with  similar  functions. 

2.2.3  Use  outside  experts  and  vendors  to  help  shape  the 
requirements. 

During  requirements  definition,  the  MRP  II  program  employed  external  experts  who 
understood  the  ramifications  of  adopting  the  MRP  II  philosophy.  These  experts  were  able  to 
assist  the  program  office  by  setting  expectations  as  to  what  the  MRP  II  philosophy  could  and 
could  not  do  and  by  providing  information  about  the  products  in  the  marketplace.  Typically, 
users  of  a  legacy  system  will  create  requirements  that  ensure  that  a  new  system  performs  in 
much  the  same  way  as  their  existing  system.  External  experts  will  question  those  legacy 
requirements,  and  such  questioning  allows  the  team  to  define  the  requirements  more 
successfully.  Given  that  requirements  are  crucial  for  every  acquisition,  using  all  of  the 
available  expertise  will  improve  the  quality  of  the  requirements.  This  leads  to  a  more 
successful  adoption  of  a  new  system.  Poorly  defined  requirements  could  have  led  to  a  system 
that  was  hard  (or  worse,  impossible)  to  use,  or  to  a  custom  solution  with  none  of  the  benefits 
of  the  COTS  market. 
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2.2.4  Pare  down  the  requirements  to  reflect  your  essential  business 
process  elements. 

The  MRP  II  requirements  definition  team  did  an  excellent  job  of  understanding  all  of  the 
requirements  and  sorting  them  into  categories  of  “must  have,”  “should  have,”  and  “nice  to 
have.”  When  the  DoD  decided  that  it  could  alter  business  processes,  many  “legacy” 
requirements  became  moot  or  entered  the  category  of  “nice  to  have.”  The  requirements  in  the 
“must  have”  category  are  those  that  embody  the  fundamental  business  processes  of  the 
depots;  all  other  requirements  are  negotiable.  In  the  world  of  COTS  software  acquisition, 
creating  a  requirement  solely  to  satisfy  an  existing  process  is  insufficient.  There  must  be  a 
strong  reason  for  the  requirement  to  exist;  otherwise  it  should  be  considered  a  preference  that 
may  be  negotiated  away. 

2.2.5  Use  the  requirements  definition  team  for  source  selection. 

The  MRP  II  program  used  the  team  that  defined  the  requirements  to  perform  the  source- 
selection  process.  This  meant  that  all  of  the  team’s  expertise  and  understanding  of  the  needs 
for  an  MRP  II  system  could  be  reused  in  source  selection.  More  importantly,  the  benefits  of 
having  a  representative  team  and  outside  experts  are  realized  at  both  source  selection  and 
requirements  definition.  An  added  benefit  of  using  the  same  team  is  that  potential 
misunderstandings  of  the  requirements  can  be  avoided.  Including  representatives  of  end  users 
in  the  team  brings  a  practical  aspect  to  source  selection — the  users  can  actually  determine  if 
the  proposals  meet  their  day-to-day  needs. 

2.2.6  The  use  of  COTS  products  may  reduce  requirements  creep. 

Every  long-lived  system  changes  over  time  in  order  to  meet  changing  or  extended  mission 
needs.  However,  for  custom-developed  systems  where  the  DoD  controls  the  source  code, 
there  is  a  danger  of  superfluous  requirements  being  added,  leading  to  requirements  creep. 
Although  the  DoD  may  request  additional  features  from  the  vendor  when  the  system  is  a 
COTS  product,  those  features  will  be  added  only  if  they  make  commercial  sense  to  the 
vendor.  The  program  office,  by  sticking  to  a  COTS  software  approach  of  no  code 
modification  and  no  vendor  custom  engineering,  can  reduce  the  tendency  for  requirements 
creep  from  the  depots.  The  depots  have  to  accept  that  the  COTS  product  operates  in  a 
particular  way  and  that  the  DoD  cannot  control  the  way  the  product  operates  —  that  is  in  the 
purview  of  WDS. 

2.2.7  Different  selection  criteria  are  needed  when  acquiring  COTS- 
based  systems. 

The  criteria  used  for  source  selection  were  weighted  in  accord  with  a  traditional  practice, 
which  is  targeted  towards  developmental  systems  rather  than  for  the  acquisition  of  a  COTS- 
based  system.  This  meant  that  not  enough  weight  was  given  to  the  demonstration  of  the 
operational  capabilities  or  the  recommendations  from  other  customers  of  the  product. 
Different  types  of  systems  may  require  different  weightings.  In  the  case  of  the  MRP  II 
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program  where  a  single  COTS  product  was  being  acquired,  more  weight  could  have  been 
given  to  product  demonstrations  and  the  way  that  industry  used  the  product. 

2.2.8  The  selection  of  COTS  products  with  considerations  for  ease 
of  integration  with  other  COTS  products  in  an  enterprise  can 
increase  the  effectiveness  of  your  investment  dollars. 

Due  to  the  application  programming  interfaces  of  the  WDS  product,  the  MRP  II  program  has 
been  able  to  connect  the  WDS  product  with  the  Oracle  Financial®  product  at  a  pilot  site, 
providing  greater  capability  to  the  enterprise. 

2.2.9  Use  contracts  that  provide  flexibility  for  needs  identified  after 
contract  award. 

One  of  the  biggest  problems  for  the  MRP  II  program  office  was  the  rigidity  of  the  contract. 
Part  way  into  the  contract,  the  need  for  additional  education,  training,  and  consulting  became 
apparent.  However,  there  was  no  way  in  the  WDS  contract  to  add  this  extra  support. 


2.2.10  Choosing  an  appropriate  vendor  is  important  to  success. 

When  acquiring  a  COTS-solution  system,  a  DoD  organization  needs  to  consider  vendor 
characteristics  (such  as  stability  or  willingness  to  work  with  the  DoD)  as  part  of  the 
acquisition.  Although  there  are  many  companies  selling  products  to  support  the  MRP  II 
philosophy,  when  it  comes  to  applying  MRP  II  principles  to  remanufacturing,  there  are  a 
limited  number  of  products  available.  WDS,  the  vendor  that  was  awarded  the  contract,  is  a 
small,  but  well-established  company,  that  had  been  selling  an  MRP  II  product  for  about  10 
years.  The  company’s  customer  support  appears  to  be  excellent,  in  that  it  continues  to  support 
customers  using  significantly  older  versions  of  the  company’s  product  as  well  as  the 
customers  using  the  latest  version. 

The  most  important  aspect  of  WDS,  however,  is  that  it  is  willing  to  work  with  the  DoD  rather 
than  for  the  DoD.  It  has  maintained  its  autonomy  and  listened  to  the  DoD  requests  for 
enhancements  rather  than  automatically  accepting  that  such  changes  must  be  made. 
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2.3  Lessons  on  Programmatic  Issues 

The  lessons  learned  about  programmatic  issues  are  discussed  below. 

2.3.1  Contract  delivery  requirements  lists  (CDRLs)  should  be 
appropriate  to  the  commercial  marketplace. 

A  result  of  purchasing  a  COTS-based  system  rather  than  developing  a  customized  system  is 
that  the  nature  of  contract  deliverables  changes.  When  a  system  is  being  developed,  the  DoD 
may  legitimately  require  deliverables  with  respect  to  the  documentation  of  the  design  and 
implementation.  However,  when  considering  a  COTS  product,  such  information  belongs  to 
the  vendor  and  may  represent  its  intellectual  property  or  reflect  its  software  development 
practices.  There  is  certainly  no  need  for  this  information  to  be  delivered  to  the  DoD.  The 
CDRLs  for  the  MRP  II  program  are  the  vendor’s  release  notes.  This  satisfies  contracting 
requirements  and  allows  the  vendor  to  operate  in  a  way  that  makes  sense  to  its  commercial 
concerns. 

2.3.2  DoD  regulations  at  the  time  of  this  program’s  inception  were 
not  helpful  in  acquiring  a  COTS  product. 

The  regulations  for  system  acquisition  (DoD  Instruction  5000.2,  Defense  Acquisition 
Management  Policies  and  Procedures)  under  which  the  MRP  II  program  had  to  operate,  were 
defined  in  accord  with  traditional  DoD  practice  (custom  development  of  new  systems).  When 
applying  these  regulations  to  the  acquisition  of  a  COTS  product,  the  MRP  II  program  found 
that  the  regulations  were  not  always  appropriate.  Typical  differences  included  the  amount  of 
detail  in  the  definition  and  flexibility  of  the  requirements,  and  the  different  documentation 
needs. 
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2.4  Lessons  on  Transition  Issues 

The  lessons  discussed  below  concern  one  aspect  of  transition  -  changing  the  culture  in  the 
receiving  organizations. 

2.4.1  If  business  practice  changes  are  required  to  use  a  COTS- 
based  system,  more  than  the  usual  level  of  education  and 
training  is  required. 

Education  and  training  play  an  important  role  in  the  introduction  of  any  new  system.  In  the 
case  of  the  MRP  II  program,  where  a  new  way  of  business  was  being  introduced  to  the 
depots,  early  education  would  have  helped  the  requirements  definition  and  source-selection 
teams  understand  the  new  approach  to  business.  Also,  early  education  would  have  helped  the 
depots  understand  how  they  could  change  their  business  processes  to  match  those  of  the  MRP 
II  philosophy.  Overall,  insufficient  resources  were  allocated  for  educating  the  depots  about 
the  MRP  II  philosophy. 

2.4.2  Early  and  creative  uses  of  education  and  training  are  effective 
ways  to  achieve  buy-in. 

One  of  the  most  important  factors  for  the  success  of  a  program  is  the  buy-in  from  all 
stakeholders-regardless  of  whether  it’s  COTS-based  or  a  custom-developed  system.  People 
using  an  existing  system  will  generally  want  any  new  system  to  operate  in  the  same  way.  Fear 
of  change  leads  to  resistance  to  the  new  system,  which  can  be  insidious  and  hard  to 
overcome.  But,  such  resistance  must  be  overcome  for  the  introduction  of  the  new  system  to 
be  successful.  Some  of  the  successful  MRP  II  deployed  sites  have  used  education  and 
training  in  creative  ways.  For  example,  the  NADEP,  Cherry  Point  focuses  some  of  its  early 
training  on  showing  its  staff  that  they  can  do  their  jobs  better  using  the  new  business 
processes  than  they  could  using  their  existing  processes.  Generally,  people  want  to  perform 
their  jobs  as  well  as  possible,  so  all  they  may  need  for  acceptance  is  to  be  shown  that 
adopting  the  new  processes  will  help  them  do  their  jobs  better. 

Another  approach  used  for  applying  education  and  training  to  overcome  resistance  was  to 
focus  training  on  understanding  the  MRP  II  philosophy  and  act  as  a  vehicle  for  resolving 
concerns  as  to  how  various  stakeholders’  jobs  would  be  affected.  In  some  cases,  education 
has  converted  detractors  into  advocates  who  have  then  gone  on  to  actively  promote  the  use  of 
the  MRP  II  philosophy. 

2.4.3  Investment  in  stakeholder  education  before  deployment  can 
decrease  the  time  to  deploy  a  new  system. 

The  NADEP,  Cherry  Point  delayed  deployment  as  long  as  possible,  using  resources  for 
education  before  deployment.  Therefore,  the  staff  responsible  for  deploying  the  system  at 
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Cherry  Point  has  a  deeper  understanding  of  the  MRP  II  philosophy  and  has  made  more  rapid 
progress  toward  full  deployment  than  most  of  the  other  sites. 

2.4.4  Training  oriented  toward  specific  classes  of  users  optimizes 
the  transition. 

Training  in  the  use  of  a  COTS-based  system  is  just  as  necessary  as  for  custom-developed 
systems.  COTS  vendors  vary  greatly  in  the  depth  and  breadth  of  their  training  materials  and, 
to  meet  the  demands  of  potentially  varied  end-user  communities,  vendor  training  is  typically 
quite  general.  Some  of  the  MRP  II  deployed  sites  found  the  vendor-provided  training  to  be 
too  broad  and  inapplicable,  and  not  of  sufficient  depth  for  some  users.  Without  training 
targeted  toward  different  types  of  users,  there  is  a  danger  that  general  training  will  lead  to 
users  applying  the  products  in  unexpected  and  possibly  inefficient  ways.  Training  targeted 
toward  a  specific  class  of  user  will  help  users  in  that  class  to  understand  the  optimal  way  to 
use  the  system  for  their  particular  job.  Program  staff  members  should  consider  the  need  for 
creating  specialized  training  for  their  organization.  Some  vendors  may  provide  customized 
training  at  an  additional  expense,  or  independent  consultants  may  be  able  to  provide  focused 
training. 

2.4.5  The  high  motivation  of  the  depots  to  stay  competitive  with  the 
commercial  repair  and  remanufacturing  world  can  greatly  aid 
in  the  transition  to  a  new  system. 

Many  of  the  maintenance  depots  were  highly  motivated  to  improve  their  business  practices. 
The  MRP  II  program  may  be  unusual  in  that  the  clients  of  the  program  office  (the  depots) 
have  a  great  desire  to  improve  the  way  they  do  business.  The  depots  realize  that  their 
business  is  repairing  DoD  assets;  they  also  realize  that  there  are  commercial  companies 
capable  of  repairing  those  same  assets.  If  the  depots  cannot  compete  with  industry,  their  jobs 
could  end  up  being  outsourced.  The  introduction  of  the  WDS  product  and  its  associated 
practices  represents  an  improvement  opportunity  for  making  the  depots  more  competitive 
with  industry. 

Depots  where  senior  leadership  has  understood  and  capitalized  on  this  important  business 
driver  as  part  of  its  transition  strategy  have  experienced  greater  success  in  transitioning  to  the 
WDS  product. 
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2.5  Lessons  on  User  Communities 

The  lessons  learned  about  user  communities  are  discussed  below. 

2.5.1  Create  your  own  user  group. 

The  MRP  II  program  created  its  own  user  group  with  a  regular  meeting  schedule.  This  group 
is  intended  to  help  the  depots  in  their  implementation  and  use  of  the  MRP  II  philosophy.  The 
meetings  are  typically  two  days  long  with  the  second  day  open  to  the  vendor.  The  main 
advantage  of  these  meetings  is  that  they  provide  a  forum  in  which  the  different  sites  may 
discuss  the  difficulties  they  are  having  in  implementation  and  the  solutions  they  are  using  to 
overcome  those  difficulties.  Because  the  user  group  consists  of  repair  depots  using  MRP  II, 
the  problems  that  one  depot  encounters  are  likely  to  be  similar  to  those  that  others  will 
encounter.  Equally,  the  solutions  that  one  depot  has  discovered  may  be  useful  to  other  depots. 
A  further  advantage  of  the  MRP  II  program  having  its  own  user  group  is  that  the  entire  group 
is  focused  on  the  business  of  repairing  DoD  assets.  Thus,  issues  of  DoD  policy  are  also 
pertinent  to  all  participants. 

Having  the  vendor  attend  at  least  a  portion  of  the  user  group  meeting  means  that  the  vendor 
can  hear  directly  from  actual  users  the  problems  that  its  DoD  customers  are  having  (and  may 
choose  to  enhance  the  product  to  avoid  those  problems).  Additionally,  the  vendor  may 
provide  advice  on  how  its  product  may  be  used  to  overcome  the  difficulties  that  the  depots 
are  having. 

2.5.2  Join  the  vendor’s  user  group. 

The  MRP  II  vendor,  WDS,  runs  a  user  group  for  all  of  its  customers.  The  MRP  II  program 
office  and  some  of  the  depots  send  representatives  to  these  meetings.  This  user  group  is 
valuable  as  it  provides  some  insight  into  the  use  of  the  product  in  the  commercial  sector. 
Future  directions  of  the  product  may  be  discussed  in  these  meetings,  providing  the  DoD  with 
the  opportunity  to  express  its  needs  in  the  field  of  remanufacturing. 

2.5.3  Join  the  appropriate  professional  and  standards  bodies. 

The  MRP  II  program  uses  CompassCONTRACT  from  WDS,  which  is  based  on  the  business 
principles  embodied  in  MRP  and  MRP  II.  Professional  organizations  and  standards  bodies 
exist  to  promote  and  support  the  MRP  II  philosophy.  Given  that  the  depot’s  business  will  be 
run  according  to  the  MRP  II  principles,  it  is  important  that  the  depots  and  the  program  office 
remain  current  with  the  direction  being  taken  by  the  MRP  II  philosophy.  This  can  be  done 
through  the  appropriate  professional  bodies.  Further,  by  being  active  in  the  professional  and 
standards  bodies,  the  DoD  is  able  to  influence  the  future  course  of  the  MRP  II  philosophy  so 
that  the  business  practices  embodied  by  the  philosophy  are  likely  to  remain  more  consistent 
with  DoD  needs.  It  should  be  noted,  though,  that  the  DoD  can  merely  influence  and  cannot 
control  the  direction  that  the  MRP  II  philosophy  takes. 
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2.6  Lessons  on  Deployment 

The  lessons  learned  about  deployment  are  discussed  below. 

2.6.1  Data  and  business  processes  have  to  be  ready  for  the  COTS 
product. 

Simply  introducing  the  product  does  not  immediately  make  life  better  for  the  depots.  Unless 
the  depots  are  prepared  for  the  product,  they  will  be  unable  to  take  advantage  of  it.  This  is 
particularly  true  when  the  product  embodies  a  new  way  of  running  the  business.  The 
preparation  required  is  to  both  modify  the  business  processes  and  ensure  that  the  data  is 
scrubbed  and  available  in  a  format  that  can  be  imported  into  the  product.  Without  appropriate 
data,  the  WDS  product  will  be  unable  to  perform  its  function.  The  accuracy  of  the  data  will, 
of  course,  affect  the  quality  of  the  product’s  output. 

2.6.2  The  program  office  is  providing  guidance  rather  than 
enforcing  a  strict  deployment  and  usage  policy. 

The  MRP  II  program  office  has  recognized  that  there  is  not  “one  true  way”  to  use  or  deploy 
the  WDS  product.  Given  that  the  different  depots  operate  in  different  ways,  it  is  important 
that  the  depots  tailor  the  product  to  their  needs  and  even  deploy  the  product  the  way  that  they 
feel  is  most  appropriate. 

Different  depots  have  adopted  different  approaches.  For  example,  the  NADEP,  Cherry  Point 
has  adopted  an  approach  where  it  takes  an  entire  process,  such  as  shop  floor  control,  from 
end  to  end,  and  deploys  that  process  using  the  WDS  product,  regardless  of  the  assets 
involved.  An  alternative,  taken  at  the  NADEP,  Jacksonville,  is  to  deploy  the  WDS  product  for 
a  particular  workload,  such  as  avionics.  Both  approaches  are  equally  valid  and  incrementally 
lead  the  depots  toward  full  implementation  using  the  MRP  II  philosophy. 

The  program  office  acts  as  a  guide  and,  to  some  extent,  as  a  center  of  expertise  on  how  the 
depots  can  deploy  the  WDS  product.  They  also  act  as  a  clearinghouse,  letting  depots  know 
what  has  (and  has  not)  worked  at  other  depots. 

2.6.3  Hiring  an  experienced  professional  to  help  deploy  a  COTS 
product  is  beneficial. 

Some  depots  were  able  to  use  consultants  with  proven  experience  in  using  and  deploying 
MRP  II  and  similar  business  systems.  This  experience  enabled  the  depots  to  leverage  proven 
methods  and  practices,  thus  making  rapid  progress  toward  full  deployment  of  MRP  II. 

Having  an  on-site  expert  in  the  technology  embodied  in  a  COTS  product  (in  this  case  MRP 
II)  allows  a  depot  to  reach  solutions  to  problems  more  quickly  and  sometimes  provides  for 
inventive  ways  around  those  problems.  The  only  danger  is  that  the  depot  staff  may  rely  on  the 
expert  rather  than  gaining  sufficient  expertise  themselves.  Ensuring  that  crucial  expert 
knowledge  is  transitioned  to  appropriate  depot  staff  can  minimize  this  risk. 
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2.6.4  There  are  advantages  to  waiting  before  deploying  an  upgrade 
release  of  a  COTS  product. 

Like  any  commercial  product,  WDS  periodically  releases  upgraded  versions  of 
Ccwi/mssCONTRACT.  The  MRP  II  program  office  works  with  WDS  to  understand  the  nature 
of  changes  in  each  release.  That  way  the  program  office  can  determine  the  probable  effects  of 
each  release  on  the  depots.  Further,  the  program  office  can.  in  some  cases,  afford  to  delay 
deployment  of  the  product  until  it  has  seen  how  the  new  release  performs  at  other  customer 
sites.  All  of  this  data  is  used  by  the  program  office  in  forming  the  recommendations  to  the 
depots  on  when  to  upgrade  to  the  new  version.  Because  the  depots  are  only  required  to 
perform  one  upgrade  a  year,  the  instability  that  occurs  from  too  many  version  upgrades  can 
be  minimized. 

2.6.5  The  DoD  underestimated  the  time  to  transition  and  deploy 
MRP  II. 

Although  the  depots  are  structured  such  that  an  order  can  be  carried  out  efficiently,  the 
transition  to  using  MRP  II  requires  a  sequence  of  steps  to  be  taken.  Each  of  those  steps  takes 
time,  regardless  of  the  willingness  of  the  participants  to  hasten  the  process.  It  takes  time  to 
examine  business  processes,  to  change  those  processes,  to  prepare  data,  and  to  train  personnel 
in  the  new  way  of  doing  business. 

This  lesson  is  subtly  different  from  the  earlier  lesson  (2.1.4)  concerning  business  process 
change  in  that  it  encompasses  the  whole  of  deployment  and  not  just  one  aspect[PWi], 

2.6.6  There  was  insufficient  contact  with  the  vendor  during 
deployment. 

During  deployment  (at  the  conference  room  pilots  and  at  other  times),  some  depots  found 
that  they  had  insufficient  assistance  from  the  vendor.  In  part,  this  may  have  been  a  cultural 
feeling,  where  the  depot  staff  expected  more  contact.  However,  this  may  also  have  been 
caused  by  the  small  size  of  WDS  (over  the  period  of  its  contract  with  the  DoD,  it  doubled  in 
size  in  order  to  handle  all  of  the  additional  work)  as  well  as  limitations  in  the  contract. 
Including  more  vendor  support  in  the  contract  could  have  avoided  this  problem. 
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2.7  Lessons  on  Vendor  Relationship  Management 

The  lessons  learned  about  managing  vendor  relationships  are  discussed  below. 

2.7.1  Do  not  buy  the  source  code. 

The  MRP  II  program  office  started  out  with,  and  maintained,  a  rigid  policy  of  refusing  to 
even  try  to  purchase  the  source  code  to  the  WDS  product.  The  consequences  of  this  policy 
have,  so  far,  proven  to  be  beneficial  to  the  MRP  II  program.  Specifically,  because  the  source 
code  is  not  available,  there  has  been  no  ability  to  modify  the  code  to  meet  a  particular 
business  process.  As  a  result,  the  office  can  accept  upgrades  from  the  vendor  as  they  are 
released  and  does  not  need  staff  to  maintain  the  code. 

2.7.2  Do  not  ask  for  DoD-specific  modifications  to  the  product. 

The  MRP  II  program  office  has  gone  further  in  terms  of  keeping  a  purely  COTS-product 
view  of  the  world.  Specifically,  they  have  asked  the  vendor  to  make  no  DoD-specific  changes 
to  the  product.  This  means  that  the  depots,  as  they  use  the  product,  are  required  to  use 
practices  in  line  with  the  rest  of  industry — after  all,  that  is  what  the  product  supports. 

2.7.3  It  is  acceptable  to  influence  the  vendor  when  asking  for 
product  enhancements. 

The  MRP  II  program  office  is  very  careful  as  to  what  changes  it  asks  the  vendor  to  make.  It  is 
trying  to  avoid  the  situation  where  the  vendor  is  maintaining  two  copies  of  the  product,  one 
for  the  DoD  and  one  for  industry.  WDS  has  been  asked  to  treat  the  DoD  as  it  would  any  other 
customer.  Specifically,  if  the  DoD  asks  for  a  particular  product  enhancement,  WDS  will  make 
that  change  only  if  it  makes  commercial  sense  to  WDS.  One  way  for  the  company  to  check 
on  the  viability  is  to  ask  its  other  customers  if  they  would  use  the  enhancement.  In  this  way, 
the  DoD  can  influence,  but  not  direct,  the  vendor. 
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3  General  Conclusions 


From  the  very  beginning,  the  MRP  II  program  office  has  explicitly  tried  to  act  as  a 
commercial  entity  and  has  encouraged  the  depots  to  operate  in  a  business-like  way.  This  has 
enabled  the  MRP  II  program  to  gain  maximum  benefit  from  the  COTS  products  available  in 
the  field  of  remanufacturing.  In  particular,  it  meant  that  the  program  office  and  the  depots 
found  COTS  products  that  could  satisfy  their  business  needs.  This  contrasts  with  the 
circumstance  where  the  DoD  defines  its  own  business  practices  and  must  acquire  customized 
software,  since  no  commercial  products  are  available  to  fill  all  DoD-specific  needs. 

The  emphasis  on  changing  business  processes  has  provided  more  benefit  to  the  DoD  than  the 
COTS  product  alone.  Each  repair  depot  has  had  the  opportunity  to  reflect  on  the  way  in 
which  it  does  business  and  to  use  the  introduction  of  the  new  product  to  change  inefficient 
practices.  Viewing  the  product  as  enabling  the  repair  depots  to  perform  their  function 
(repairing  DoD  assets)  rather  than  institutionalizing  existing  practices  means  that  the  product 
assists  rather  than  drives  the  function  of  the  depots.  The  emphasis  on  changing  business 
processes  has  been  coupled  with  an  emphasis  on  educating  and  training  the  depot  staff  in 
both  the  MRP  II  philosophy  and  the  specific  product.  This  educational  emphasis  has 
accelerated  progress  toward  full  use  of  the  WDS  system. 

The  decisions  not  to  buy  the  source  code  and  to  use  the  product  as  sold  rather  than  with  DoD- 
specific  modifications  have  been  essential  factors  in  the  success  of  the  MRP  II  program. 

These  decisions  mean  that  the  vendor,  WDS,  is  not  making  a  special  version  of  its  product  for 
DoD  use.  When  the  DoD  acquires  COTS  products  modified  specifically  for  the  DoD,  there  is 
always  the  danger  that  the  vendor  will  have  a  limited  commitment  to  the  product,  losing 
many  of  the  advantages  of  acquiring  COTS  products.  The  MRP  II  program  has  avoided  this 
danger  by  following  commercial  practice  rather  than  dictating  that  the  new  product  must 
operate  in  some  DoD-specific  fashion. 

The  relationship  between  the  program  office  and  WDS  is  that  of  customer  and  vendor  rather 
than  the  traditional  one  of  government  and  contractor.  This  has  meant  that  the  depots  and 
WDS  can  concentrate  on  their  separate  businesses  (repairing  assets  and  making  a  profit  by 
selling  MRP  II  technology).  This  has  resulted  in  a  cooperative  rather  than,  as  often  happens, 
an  adversarial  relationship. 
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For  Additional  Information 


To  reach  us  for  additional  information  or  assistance,  use  the  contact  information  below  or 
visit  our  Internet  site  at  http://www.sei.cmu.edu/cbs. 


Lisa  Brownsword 
Software  Engineering  Institute 
Carnegie  Mellon  University 
1403  Wilson  Boulevard,  Suite  902 
Arlington,  VA  22203 

Voice:  (703)908-8203 
Fax:  (703)908-9317 
Email:  llb@sei.cmu.edu 


Patrick  Place 

Software  Engineering  Institute 
Carnegie  Mellon  University 
4500  Fifth  Ave 
Pittsburgh,  PA  15213 

Voice:  (412)  268-7746 
Fax:  (412)  268-5758 
Email:  prp@sei.cmu.edu 


CMU/SEI-99-TN-01 5 


21 


REPORT  DOCUMENTATION  PAGE 

Form  Approved 

OMB  No.  0704-0188 

Public  reporting  burden  tor  this  collection  of  information  is  estimated  to  average  1  hour  per  response,  including  the  time  for  reviewing  instructions,  searching  existing  data  sources,  gathenng  and 
maintaining  the  data  needed,  and  completing  and  reviewing  the  collection  of  information.  Send  comments  regarding  this  burden  estimate  or  any  other  aspect  of  this  collection  of  information, 
including  suggestions  for  reducing  this  burden,  to  Washington  Headquarters  Services,  Directorate  for  information  Operations  and  Reports,  1215  Jefferson  Davis  Highway,  Suite  1204,  Arlington, 

VA  22202-4302  and  to  the  Office  of  Management  and  Budget,  Paperwork  Reduction  Project  (0704-0188),  Washington,  DC  20503. _ „ _ T _ _ _ 

1 .  AGENCY  USE  ONLY  (LEAVE  BLANK) 

2.  REPORT  DATE 

June  2000 

3.  REPORT  TYPE  AND  DATES 

COVERED 

Final 

4.  TITLE  AND  SUBTITLE 

Lessons  Learned  Applying  Commercial  Off-the-Shelf  Products 

Manufacturing  Resource  Planning  II  Program 

5.  FUNDING  NUMBERS 

C  — F19628-95-C-0003 

6.  author(s) 

Lisa  Brownsword,  Patrick  Place 

7.  PERFORMING  ORGANIZATION  NAME(S)  AND  ADDRESS(ES) 

Software  Engineering  Institute 

Carnegie  Mellon  University 

Pittsburgh,  PA  15213 

8.  PERFORMING  ORGANIZATION 

REPORT  NUMBER 

CMU/SEI-99-TN-01 5 

9.  SPONSORING/MONITORING  AGENCY  NAME(S)  AND  ADDRESS(ES) 

HQ  ESC/DIB 

5  Eglin  Street 

Hanscom  AFB,  MA  01 731  -21 1 6 

10.  SPONSORING/MONITORING 

AGENCY  REPORT  NUMBER 

1 1 .  SUPPLEMENTARY  NOTES 

12. A  DISTRIBUTION/AVAILABILITY  STATEMENT 

Unclassified/Unlimited,  DTIC,  NTIS 

12.B  DISTRIBUTION  CODE 

1 3.  ABSTRACT  (MAXIMUM  200  WORDS) 

While  the  lure  of  easy  system  construction  from  pre-existing  building  blocks  that  snap  into  place  is  appealing, 
current  reality  reveals  a  less  than  ideal  picture,  particularly  for  commercial  off-the-shelf  (COTS)  software 
components.  Examining  the  similarities  and  differences  of  organizations  that  have  applied  COTS  and  the 
successes  and  failures  of  those  organizations  has  enabled  the  COTS-Based  Systems  (CBS)  Initiative  at  the 
Software  Engineering  Institute  (SEI)  to  identify  a  number  of  significant  capabilities  that  an  organization  must  have 
to  succeed  with  a  COTS-based  approach.  This  case  study  of  the  Manufacturing  Resource  Planning  II  program  is 
part  of  a  series  of  case  studies  that  seek  to  identify  important  acquisition,  business,  and  engineering  issues 
surrounding  the  use  of  COTS-based  systems  and  thus  derive  available  solutions,  where  possible. 

14.  SUBJECT  TERMS 

commercial  item,  COTS,  COTS-based  systems, 
project  management 

15.  NUMBER  OF  PAGES 

29pp 

16.  Price  Code 

17.  SECURITY  CLASSIFICATION  18.  SECURITY  CLASSIFICATION 

OF  REPORT  OF  THIS  PAGE 

UNCLASSIFIED  UNCLASSIFIED 

1 9.  SECURITY  CLASSIFICATION 

OF  ABSTRACT 

UNCLASSIFIED 

20.  LIMITATION  OF  ABSTRACT 

UL 

NSN  7540-01-280-5500 


Standard  Form  298  (Rev.  2-89) 
Prescribed  by  ANSI  Std.  Z39-18 
298-102 


